1. Field of the Invention
The technology relates to network test equipment simulating a network. Separately, the technology relates to the generation of network test packets and/or the generation of parts of network test packets.
2. Description of Related Art
The technology disclosed includes a hardware architecture for methods and apparatuses used to test routers, switches and the like, particularly high volume infrastructure devices.
Network test equipment tests component network equipment such as routers and edge devices, by simulating network traffic from and/or to an emulated network, thereby sparing the trouble of actually setting up a real network having the complexity of the emulated network. To assemble and send traffic and to receive and characterize received traffic, present network test equipment relies significantly on a large amount of fast memory, such as SRAM, connected to an FPGA.
This network test equipment architecture of i) a microprocessor and ii) an FPGA connected to a large amount of fast memory (SRAM), arose from the slow links (e.g., PCI) connecting the microprocessor and the FPGA. Such links have been historically simply too slow to keep up with the demands of the FPGA to send and/or receive traffic. Because the FPGA frequently interacts with the memory structures required to send and/or receive traffic, if the fast memory were connected to the microprocessor rather than the FPGA, then the links between the microprocessor and the FPGA would be overwhelmed.
Accordingly, this fast memory is connected to the FPGA, to minimize latency of communicating packet ingredients and other data with the FPGA. This is in contrast with slow memory, such as DRAM, acting as the main memory for a microprocessor.
Unfortunately, fast memory is expensive, and the desired quantity of fast memory continues to steadily increase. This expected increase in the amount of fast memory connected to the FPGA is driven by the increasing capability of network equipment, which in turn increases the requirements of network test equipment. The expected design trend is to continue to increase the quantity of fast SRAM connected to the FPGA.
The slow links connecting the microprocessor and the FPGA contribute to the quantity of required SRAM. Such links are too slow to keep up with the demands of the FPGA to send and/or receive traffic on a “live” basis. In particular, the CPU cannot generate data required by the FPGA, such as ingredients for outgoing test packets, on an ongoing basis as the FPGA generates outgoing test packets. Instead, prior to any significant amount of test packet generation by the FPGA, the CPU must generate all of the required ingredients for outgoing test packets, and again prior to any significant amount of test packet generation by the FPGA, all of these ingredients must be transferred over the slow links to SRAM connected to the FPGA. In more recent architectures, this has required some 24 megabytes of expensive fast SRAM connected to the FPGA, largely to store all of these ingredients to be quickly accessible by the FPGA during the test packet generation by the FPGA.
Due to the requirements that, prior to any test packet generation by the FPGA, the CPU must i) generate the complete tables, and ii) transfer the complete table contents over to the SRAM connected to the FPGA, the tables in the SRAM connected to the FPGA must be “over inclusive”. These tables include not only entries that are used by the FPGA eventually to make test packets, but also entries that will not used by the FPGA eventually to make test packets. Prior to any test packet generation by the FPGA, when the tables are transferred from the CPU to the SRAM connected to the FPGA, the FPGA is not making any test packets, and the FPGA is not requesting particular data required to assemble packets. When the SRAM connected to the FPGA is being filled by the tables generated by the CPU, the FPGA simply takes the data from the CPU and puts the data into the correct SRAM connected to the FPGA.
In a prior release of Spirent TestCenter™, the following tables of data are generated by the CPU and transferred to the SRAM connected to the FPGA, prior to generating any test packets: i) a frame sequence table, ii) frame control structures table, iii) base content table, and iv) modifier parameters table. To make a frame, the FPGA first reads the next entry of the frame sequence table. The frame sequence table has a sequence of 8 byte entries which each define a frame, by pointing to particular entries of the frame control structures table, the base content table, and modifier parameters table. Then, the FPGA accesses the entries of the frame control structures table and the base content table, as identified by the entry of the frame sequence table, and makes a frame template. Finally, the FPGA accesses the entry of the modifier parameters table, as identified by the entry of the frame sequence table. At this time, the FPGA not only retrieves the locations in the frame that must be modified, but also the raw input data required by the FPGA to calculate the modifier values inserted by the FPGA. Accordingly, the modifier parameters table is relatively complicated, and includes a starting value, ending value, stutter counter, 6-8 parameters, increment/decrement/random indicators, and offset values to identify the location(s) of the frame to insert the eventual modifier values calculated by the FPGA using the entry of the modifier parameters table.
The resulting cost penalty on the bill of materials including the fast SRAM to store all these tables is substantial, such that the cost of fast SRAM alone is roughly half the cost of parts for manufacturing such test equipment. Nevertheless, the increased bill of materials is viewed as a requirement, because of the requirements to support a wide variety of test traffic requiring a wide variety of test packet ingredients, and because of the previously discussed bottleneck on data transfers of these test packet ingredients between the FPGA and microprocessor.